In cryptographic systems such as a public key infrastructure (PKI), certificates can be used to encrypt messages such that only a holder of a private key associated with a specific certificate can read the message, and to digitally sign information to prove that the private key holder is the source of the information. Digital signatures provide an effective, universally verifiable form of authentication. As in any system, a PKI is subject to security breaches.
Digital certificates facilitate the use of digital signatures by providing a guarantee that a particular public key belongs to a specific identity and, therefore, ensuring that the public key can be used to verify the signature. Digital certificates include a unique certificate serial number, a public key, and a user's name, bound together by a certificate authority's (CA's) digital signature. Many types of digital certificates are used, such as email certificates, encryption certificates, signing certificates, and so on.
A digital certificate is associated with a unique public key pair having a unique private key and a unique public key. When a third party obtains a copy of the unique private key, the certificate associated with it becomes compromised. To mitigate the security breach that occurs when a certificate is compromised, CAs publish certificate revocation lists (CRLs) that indicate which certificates can still be trusted.
There are three conventional methods by which certificate revocation information is propagated to clients. In a first conventional method, clients download CRLs directly from certificate authorities. In a second conventional method, an online certificate status protocol (OCSP) is used to distribute certificate revocation information to clients.
FIG. 1 illustrates a conventional PKI architecture 100 for propagating certificate revocation information to clients according to the second conventional method. A certificate authority (CA) 103 generates a CRL 115 and transmits it 150 to an OCSP responder 105. The OCSP responder 105 is a secure server that has authority granted to it by the CA 103 to generate OCSP responses 124.
A relying party device 110 receives a message transmittal 164 from a mail server 113, the contents of which include a signed message 130. A certificate revocation determiner 126 residing on the relying party device 110 accesses the signed message 130 to check whether a certificate that was used to generate a cryptographic signature for the signed message 130 has been revoked. This is accomplished by sending an OCSP response query 172 to the OCSP responder 105.
Upon receiving the OCSP response query 172 for a particular certificate from the relying party device 110, the OCSP responder 105 generates an OCSP response 124 with an OCSP response generator 118 according to the CRL 115. The OCSP response 124 indicates whether the certificate for which the OCSP response 124 was requested has been revoked. Each OCSP response 124 relates to only a single certificate, and must be digitally signed 154 with a private key 120 associated with the OCSP responder 105 to verify the validity of the OCSP response 124. Once OCSP response 124 is generated 153 and signed 154, it is transmitted to the relying party device 110 that requested it.
A third conventional method for propagating certificate revocation information to clients is illustrated in FIG. 2. In the third conventional method, a CA 203 transmits a CRL 215 to an OCSP responder 205. The OCSP responder 205 generates OCSP responses 253 with an OCSP response generator 217, and digitally signs them 254 with a private key 222. The OCSP responses 224 are generated and signed once a day before client queries are made, and are referred to as pre-signed (or pre-generated) OCSP responses. Each pre-signed OCSP response includes revocation status information for twenty sequentially numbered certificates. Pre-signed OCSP responses 224 are transmitted 262 to third party a server 213.
A relying party device 210 receives a message transmittal 264 from a mail server 213, the contents of which include a signed message 230. A certificate revocation determiner 226 accesses 267 the signed message 230 to check whether a certificate that was used to generate a cryptographic signature on the signed message 230 has been revoked. This is accomplished by sending an OCSP response query 272 to third party server 213 regarding the certificate in question. Third party server 213 transmits 275 a pre-signed OCSP 224 response that includes an entry for the certificate inquired about.
Response queries for OCSP and other certificate validation protocols may include a nonce (a random string of values used to ensure that old communications cannot be reused). For a response transmittal to be accepted, the nonce must be included in the response. The use of a nonce in the response query forces a fresh response to be generated. Therefore, if a nonce is used, pre-signed responses (as described in method three and FIG. 2) cannot be used by conventional systems to respond to the query. Moreover, in conventional systems only a single nonce may be included in a response.